Methods and apparatus for verifying context participants in a context management system in a networked environment

ABSTRACT

Methods and apparatus related to context management in a networked environment are provided. According to one aspect, technique is employed to verify that a remote application is emulated on the same client as at least one other application in a context by receiving from the client and the remote application server information that uniquely identifies the client.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.10/632,690, filed Aug. 1, 2003, entitled “Methods And Apparatus ForVerifying Context Participants In A Context Management System In ANetworked Environment,” the entirety of which is incorporated herein byreference.

FIELD OF THE INVENTION

The present invention relates to techniques for managing context amongsoftware applications in a networked environment.

BACKGROUND OF THE INVENTION

There exist commercial endeavors in which a plurality of computerapplications share a set of entities or subjects which are common to theapplications. For example, in the field of medicine, a user may provideinput describing a given patient to multiple applications. The input maybe clinical information, such as x-ray images or blood work results,financial information, such as insurance coverage or billing history, orother types of information. The user's task historically entailedrepeating the entry of data identifying the patient into the multipleapplications. Although patient data is an illustrative example, thispractice extends to data describing other subjects as well, such as auser (i.e., to enable “single sign-on,” wherein a user logs in to asingle network-based resource and is automatically given access to otherauthorized network-based resources), patient encounter, clinicalprovider, observation, insurer, or other subject. The use of sharedinformation among multiple applications is not limited to the medicalfield.

Data which describes a given subject, and which is used commonly by aplurality of applications, is referred to herein as a “context” definedby that subject. The desirability of managing context in the healthcareindustry, so that a user need not repeatedly enter information for asubject into multiple applications, has been recognized. To this end, astandard for context management, known as the Health Level 7 (HL7)context management specification, was published in 1999 by the ClinicalContext Object Workgroup (CCOW). The CCOW standard defines a contextmanagement architecture (CMA) and processes for managing informationdescribing a subject across a range of clinical and otherhealthcare-related applications.

Among other features, the CCOW standard defines interfaces forinter-process communication, including communication betweenapplications and a software-based module which coordinates themodification of data across applications (the “context manager”). Oneembodiment of a context manager is described in commonly-assigned U.S.patent application Ser. No. 09/545,396, which is incorporated herein byreference.

The interfaces (“technology mappings”) defined by CCOW provide forcommunication between the context manager and various “styles” ofapplications, including those which follow the Microsoft Common ObjectModel (COM) and Hypertext Transport Protocol (HTTP) conventions, amongothers. For example, for a COM-based application, the CCOW standardspecifies COM interfaces which allow the COM-based application toexchange data and parameters with the context manager when using a CCOWcompliant context management system. The interfaces may be programmed toprocess COM-based data and parameters provided by the context managerand context participant applications to support the context managementfunctions.

FIG. 1 depicts an exemplary context management system, in which acontext manager 230 manages context for two context participantapplications 210 and 220. Applications 210 and 220 may execute on thesame or separate computers, and the computer(s) may be the same orseparate from a computer on which context manager 230 executes.Communication between the processes may be enabled via any of numerouscombinations of protocols and physical communications devices orcomponents. For example, when the applications 210, 220 and/or thecontext manager 230 execute on the different computers interconnect by anetwork (e.g., a local area network), the TCP/IP protocol may beemployed.

According to the CCOW standard, communication between the applicationsin a context and the context manager is facilitated through the use ofcontext participant (CP) interfaces for the applications and a set ofcontext manager (CM) interfaces for the context manager. Each of the CPand CM interfaces may comprise any of numerous suitable components forenabling inter-process communication. In one embodiment, each of the CPand CM interfaces is integrated in an associated application andprovides a “plug” which enables communication with the application(e.g., CP interfaces 217, 227 may be implemented within applications210, 220 respectively, and CM interface 235 may be implemented in anapplication program executing on the computer on which the contextmanager 230 executes). In the illustrative system of FIG. 1, theapplications 210, 220 have CP interfaces 217, 227, respectively,associated with them.

Context participant (CP) interfaces 217 and 227, respectively, receivecommunications from context manager 230 on behalf of applications 210,220. Applications 210, 220 may receive communications from the contextmanager 230 in a format and style commensurate with the CCOW standard(e.g., as COM messages or HTTP encoded messages over TCP/IP). In theembodiment shown, the communications pass through code portions 214 and224 associated with the applications. CP interfaces 217, 227 mayalternatively be incorporated directly into applications 210, 220 asdescribed above, and directly pass communications thereto. As a furtheralternative, a CP wrapper or bridge can be provided that performs thefunction of the CP interface 217, 227, and allows an application tocommunicate according to the CCOW standard, without requiring anymodification of the application itself. Context manager (CM) interface235 receives communications from applications 210 and 220 and forwardsthose communications to the context manager 230.

As mentioned above, each of applications 210 and 220 includes a seriesof programmed routines integrated with the respective application codeto perform context management support functions as defined by the CCOWstandard. For example, applications 210 and 220 include code portionsenabling communication with the context manager. Specifically, withinapplication 210, code portion 212 defines messages sent to the CMinterface 235, and code portion 214 implements the CP interface 217.Similarly, application 220 includes code portions 222 and 224 that,respectively, perform the same functions as code portions 212 and 214.

When a user of one of the applications (e.g., application 210) desiresto switch the context by changing the data for a subject (e.g.,switching from one patient to another), the application sends a requestto the context manager 230 (via CM interface 235). The requestingapplication is referred to as an “instigator” of the requested change inthe context.

When the context manager receives a request to change a subject of thecontext, context manager 230 surveys the other applications in thecontext (e.g., application 220), to determine whether the switch isacceptable to them. The context manager 230 performs the survey bysending a request to the other applications (e.g., application 220) viatheir associated CP interfaces. The other applications in the contextmay determine whether the subject change is acceptable or conditionallyacceptable. While rules defining the acceptability of a subject changemay be customized for specific applications and contexts, an example ofa situation where a requested change may be conditionally acceptable isif data relating to the existing subject has not yet been written topermanent memory on the computer on which the application executes. Inthis example, the other application may respond to the survey byalerting the instigator that the data could be lost if a changeproceeded. The surveyed applications respond to the survey bytransmitting messages back to the context manager 230 describing theirreactions to the requested change.

According to the CCOW standard, the context manager 230 communicates theresults of the survey to the instigator application, and a user thereofexamines the results and determines how to proceed. There are a range ofoptions that the user can select, including canceling the requestedchange, executing the requested change, or removing the instigatorapplication from the context. Any of these options can be selected bythe user irrespective of the results of the survey. For example, if oneor more of the surveyed applications indicates that the requested changeis unacceptable to it, the instigator application may nevertheless forcethe context change, or alternatively, may simply remove itself from thecontext so that the instigator application can implement whateverchanges it desires without impacting the other applications in thecontext. After the user decides how to proceed with the requestedchange, a call is made by the instigator application to the contextmanager 230 informing the context manager of the change decision. Thecontext manager then makes one or more calls to publish the changedecision by notifying the other applications in the context of thedecision.

While CCOW supports context sharing among a number of different types ofapplications such as COM-based applications, HTTP or web-basedapplications, applications executed on a remote server and emulated on aclient (e.g., using the Citrix MetaFrame and ICA client architecture),and others, CCOW does not define any implementation for enablingapplications of different types to communicate in a manner thatfacilitates context sharing. In addition, in the example discussed abovein connection with FIG. 1, it is assumed that communications can flowfreely between the context manager and the computers on which theapplications in the context are executing. However, in many networkedenvironments that have security measures in place, that is not the case.

Various embodiments of the present invention are directed to techniquesfor performing context management in a networked environment.

SUMMARY OF THE INVENTION

One embodiment of the invention provides a method, in a systemcomprising a client, a context management (CM) server and a network thatcouples the client to the server, the client executing at least oneclient application that shares a context with another application for aperiod of time, the CM server executing a context management service tomanage the context, of facilitating communication between the client andthe CM server. The method comprises acts of: (a) establishing aconnection, through the network, between the client and the CM server toenable communication between the CM server and the client; and (b)maintaining the connection between the client and the CM server for theperiod of time during which the at least two applications share thecontext. The act (a) may further comprise establishing a backchannelconnection between the client and the CM server through TCP/IP.

Another embodiment of the invention provides a method, in a systemcomprising at least one client, at least one web server, and a contextmanagement (CM) server coupled to the at least one client and the atleast one web server, the at least one client and the at least one webserver executing a plurality of applications that share a context, theplurality of applications comprising at least one web application thatis executed on the web server, the at least one client having at leastone browser that enables the at least one client to access the at leastone web application, the CM server executing a context managementservice to manage the context, of facilitating a requested change in atleast one aspect of the context, the requested change being initiated byan instigator from among the plurality of applications. The methodcomprises acts of, in response to a change decision being reached as towhether each of the plurality of applications is amenable to therequested change: (a) publishing the change decision directly from theCM server to the plurality of applications; and (b) contacting the atleast one browser directly from the CM server, so that the instigatorneed not contact the at least one browser, to inform the browser thatits corresponding at least one web application has been updated.

Yet another embodiment provides a method, in a system comprising a firstclient, a context management (CM) server, a remote application serverand at least one network that couples together the first client, the CMserver and the remote application server, the remote application serverexecuting at least one remote application, the first client executing atleast one client application that may share a context with the at leastone remote application, the first client further executing an emulationapplication that emulates that at least one remote application on thefirst client, the CM server executing a context management service tomanage the context, of verifying that the at least one remoteapplication is emulated on the first client and may belong to the samecontext. The method comprises acts of: (a) receiving from the firstclient first information that uniquely identifies an aspect of the firstclient; (b) receiving from the remote application server secondinformation that uniquely identifies the aspect of a remote client onwhich the remote application is emulated; and (c) determining that theat least one remote application is emulated on the first client and maybelong to the same context when the first information matches the secondinformation.

Yet another embodiment provides a method, in a system comprising atleast one client, a context management (CM) server, a plurality ofremote application servers and at least one network that couplestogether the at least one client, the CM server and the plurality ofremote application servers, the plurality of remote application serverscomprising first and second remote application servers respectivelyexecuting first and second remote applications that are emulated on theat least one client and may share a context, the at least one clientexecuting at least one emulation application that emulates the first andsecond remote applications on the at least one client, the CM serverexecuting a context management service to manage the context, ofverifying that the first and second remote applications are emulated ona same client and may belong to a same context. The method comprisesacts of: (a) receiving from the first remote application server firstinformation that uniquely identifies an aspect of the client on whichthe first remote application is emulated; (b) receiving from the secondremote application server second information that uniquely identifies anaspect of the client on which the second remote application is emulated;and (c) determining that the first and second remote applications areemulated on the same client and may belong to the same context byexamining the first information and the second information.

Yet another embodiment provides at least one computer-readable mediumencoded with instructions for performing a method in a system comprisinga client, a context management (CM) server and a network that couplesthe client to the server, the client executing at least one clientapplication that shares a context with another application for a periodof time, the CM server executing a context management service to managethe context, the method for facilitating communication between theclient and the CM server. The method comprises acts of: (a) establishinga connection, through the network, between the client and the CM serverto enable communication between the CM server and the client; and (b)maintaining the connection between the client and the CM server for theperiod of time during which the at least two applications share thecontext.

Yet another embodiment provides at least one computer-readable mediumencoded with instructions for performing a method in a system comprisingat least one client, at least one web server, and a context management(CM) server coupled to the at least one client and the at least one webserver, the at least one client and the at least one web serverexecuting a plurality of applications that share a context, theplurality of applications comprising at least one web application thatis executed on the web server, the at least one client having at leastone browser that enables the at least one client to access the at leastone web application, the CM server executing a context managementservice to manage the context, the method for facilitating a requestedchange in at least one aspect of the context, the requested change beinginitiated by an instigator from among the plurality of applications. Themethod comprises acts of, in response to a change decision being reachedas to whether each of the plurality of applications is amenable to therequested change: (a) publishing the change decision directly from theCM server to the plurality of applications; and (b) contacting the atleast one browser directly from the CM server, so that the instigatorneed not contact the at least one browser, to inform the browser thatits corresponding at least one web application has been updated.

Yet another embodiment provides at least one computer-readable mediumencoded with instructions for performing a method in a system comprisinga first client, a context management (CM) server, a remote applicationserver and at least one network that couples together the first client,the CM server and the remote application server, the remote applicationserver executing at least one remote application, the first clientexecuting at least one client application that may share a context withthe at least one remote application, the first client further executingan emulation application that emulates that at least one remoteapplication on the first client, the CM server executing a contextmanagement service to manage the context, the method for verifying thatthe at least one remote application is emulated on the first client andmay belong to the same context. The method comprises acts of: (a)receiving from the first client first information that uniquelyidentifies an aspect of the first client; (b) receiving from the remoteapplication server second information that uniquely identifies theaspect of a remote client on which the remote application is emulated;and (c) determining that the at least one remote application is emulatedon the first client and may belong to the same context when the firstinformation matches the second information.

Yet another embodiment provides at least one computer-readable mediumencoded with instructions for performing a method in a system comprisingat least one client, a context management (CM) server, a plurality ofremote application servers and at least one network that couplestogether the at least one client, the CM server and the plurality ofremote application servers, the plurality of remote application serverscomprising first and second remote application servers respectivelyexecuting first and second remote applications that are emulated on theat least one client and may share a context, the at least one clientexecuting at least one emulation application that emulates the first andsecond remote applications on the at least one client, the CM serverexecuting a context management service to manage the context, the methodfor verifying that the first and second remote applications are emulatedon a same client and may belong to a same context. The method comprisesacts of: (a) receiving from the first remote application server firstinformation that uniquely identifies an aspect of the client on whichthe first remote application is emulated; (b) receiving from the secondremote application server second information that uniquely identifies anaspect of the client on which the second remote application is emulated;and (c) determining that the first and second remote applications areemulated on the same client and may belong to the same context byexamining the first information and the second information.

Yet another embodiment provides a context management server for use in asystem comprising a client, the context management server and a networkthat couples the client to the context management server, the clientexecuting at least one client application that shares a context withanother application for a period of time. The context management servercomprises: at least one processor to execute a context managementservice to manage the context; and at least one controller thatmaintains a connection through the network with the client for theperiod of time during which the at least two applications share thecontext.

Yet another embodiment provides a context management (CM) server for usein a system comprising at least one client, at least one web server, anda context management server coupled to the at least one client and theat least one web server, the at least one client and the at least oneweb server executing a plurality of applications that share a context,the plurality of applications comprising at least one web applicationthat is executed on the web server, the at least one client having atleast one browser that enables the at least one client to access the atleast one web application. The CM server comprises: at least oneprocessor to execute a context management service to manage the context;and at least one controller that: facilitates a requested change in atleast one aspect of the context, the requested change being initiated byan instigator from among the plurality of applications; and in responseto a change decision being reached as to whether each of the pluralityof applications is amenable to the requested change: (a) publishes thechange decision directly to the plurality of applications; and (b)contacts the at least one browser directly, so that the instigator neednot contact the at least one browser, to inform the browser that itscorresponding at least one web application has been updated.

Yet another embodiment provides a context management server for use in asystem comprising a first client, the context management server, aremote application server and at least one network that couples togetherthe first client, the context management server and the remoteapplication server, the remote application server executing at least oneremote application, the first client executing at least one clientapplication that may share a context with the at least one remoteapplication, the first client further executing an emulation applicationthat emulates that at least one remote application on the first client.The context management server comprises: at least one processor toexecute a context management service to manage the context; and at leastone controller that: receives from the first client first informationthat uniquely identifies an aspect of the first client; receives fromthe remote application server second information that uniquelyidentifies the aspect of a remote client on which the remote applicationis emulated; and determines that the at least one remote application isemulated on the first client and may belong to the same context when thefirst information matches the second information.

Yet another embodiment provides a context management server for use in asystem comprising at least one client, the context management server, aplurality of remote application servers and at least one network thatcouples together the at least one client, the context management serverand the plurality of remote application servers, the plurality of remoteapplication servers comprising first and second remote applicationservers respectively executing first and second remote applications thatare emulated on the at least one client and may share a context, the atleast one client executing at least one emulation application thatemulates the first and second remote applications on the at least oneclient. The context management server comprises: at least one processorto execute a context management service to manage the context; and atleast one controller that: receives from the first remote applicationserver first information that uniquely identifies an aspect of theclient on which the first remote application is emulated; receives fromthe second remote application server second information that uniquelyidentifies an aspect of the client on which the second remoteapplication is emulated; and determines that the first and second remoteapplications are emulated on the same client and may belong to the samecontext by examining the first information and the second information.

Yet another embodiment provides a client computer for use in a systemcomprising the client computer, a context management (CM) server and anetwork that couples the client to the CM server. The client computercomprises: at least one processor to execute at least one clientapplication that shares a context with another application for a periodof time; and at least one controller that maintains a network connectionwith the CM server for the period of time during which the at least twoapplications share the context.

Yet another embodiment provides a method, in a system comprising anapplication computer executing an application that shares a context withat least one other application, a context management (CM) serverexecuting a context management service to manage the context, a networkthat couples the application computer to the CM server, and a networksecurity facility creating a boundary between a protected environmentand an external environment, wherein one of the application computer andthe CM server is disposed in the protected environment and the other isdisposed in the external environment, and wherein the network securityfacility prevents direct connections between the application computerand the CM server from being initiated by the one of the applicationcomputer and the CM server disposed in the external environment, offacilitating communication between the application computer and the CMserver. The method comprises acts of: (a) providing a gateway computerin the protected environment; (b) enabling the one of the applicationcomputer and the CM server that is disposed in the external environmentto initiate a connection with the gateway computer; and (c) passing atleast one communication, through the gateway computer, from the one ofthe application computer and the CM server disposed in the externalenvironment to the other to enable the one of the application computerand the CM server disposed in the external environment to initiatecommunication with the other.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an exemplary implementation of a context manager and aplurality of context participant applications according to the priorart;

FIG. 2 depicts an exemplary context management system, implemented in anetworked environment, in which aspects of the present invention may beimplemented;

FIG. 3 depicts an exemplary system configuration having nested layers ofremotely emulated applications, and on which aspects of the presentinvention may be implemented;

FIG. 4 depicts an exemplary system configuration in which a clientapplication and a context management server are disposed in protectedand external areas created by a network security facility, respectively,and on which aspects of the present invention may be implemented; and

FIG. 5 depicts an exemplary system configuration in which serverapplications and a context management server are disposed in externaland protected areas created by a network security facility,respectively, and on which aspects of the present invention may beimplemented.

DETAILED DESCRIPTION

Aspects of the present invention are directed to facilitating contextmanagement in a networked environment. As used herein, contextmanagement refers to the sharing of numerous types of subject data, andincludes the sharing of only user information in a single sign-onenvironment.

One issue that arises in networked environments relates to the use ofvirtual private networks (VPNs), network firewalls, or other securityfacilities which employ network address translation (NAT) or similaridentity masking features. NAT converts the Internet Protocol (IP)addresses of client machines situated “behind” the firewall or VPN toone or more “masked” IP addresses which it presents to networkcomponents outside of the firewall. Though a NAT facility keeps track ofmessages being transmitted from a client behind a firewall to an outsidedevice, and may perform a reverse conversion to allow a response to besent back to the appropriate client while a connection is maintained, iteffectively keeps client IP addresses hidden from outside devices sothat the outside devices can not transmit unsolicited messages directlyto the protected clients.

When the context manager executes on a server disposed outside afirewall employing NAT or other masking feature, it may be unable toinitiate communication with a context participant application executingon a client behind the firewall. According to one aspect of theinvention, a technique is employed for facilitating communicationbetween a client and the context manager, whereby connection through thenetwork is maintained between the client and the context manager for theperiod during which the client shares a context managed by the contextmanager.

In another aspect of the present invention, the CCOW standard ismodified. As discussed below, according to the CCOW standard, theinstigator application is charged with touching the browser for anyweb-based application in the context to inform the browser that a changedecision has been published. Networked environments may exist whereinthe instigator application and one or more browsers that correspond toweb applications in the context are employed on opposite sides of afirewall or other security facility that effectively prevents directcommunication between them. Thus, in accordance with one embodiment ofthe present invention, the context manager touches the affectedbrowsers, thereby making it unnecessary for the instigator applicationto directly communicate with the browsers that correspond to webapplications in the context.

Two other embodiments of the present invention specifically relate toemulated applications, wherein the application is executed on a remoteapplication server and is emulated on a client (e.g., the CitrixMetaFrame and ICA architecture mentioned above). In one embodiment,techniques are employed to ensure that an application executing on aremote application server belongs to a same desktop as the otherapplications in the shared context, to protect the integrity of thecontext. In another aspect, techniques are employed to ensure that tworemotely executing applications are emulated on a same client, and cantherefore belong to a same context, to protect the integrity of thecontext.

FIG. 2 depicts an exemplary context management implementation comprisinga context manager and a number of context participant applicationsconnected in a networked environment. It should be appreciated thatvarious features and components of the system depicted in FIG. 2 areprovided for illustrative purposes only, as the aspects of the presentinvention described below can be implemented on networked computersystems having numerous other configurations.

In the illustrative system of FIG. 2, a desktop 300 (which may beexecuted on a single computer) executes three basic types ofapplications i.e., a COM-based application 310, a browser 330 for aweb-based application executing on a web server 500, and an emulationclient 340 (e.g., a Citrix Independent Computing Architecture (ICA)client) emulating an application executing on a remote applicationserver (i.e., a Citrix MetaFrame server) 600.

As discussed above, COM-based application 310 is an application whichcomplies with Microsoft's Common Object Model. For example, application310 may be a Windows-based application which is used to maintain, forexample, patient x-ray data, although numerous other possibilitiesexist.

In the embodiment shown, desktop 300 also includes a COM adapter 320 tofacilitate communication between applications that employ differentcommunication protocols (e.g., application 310 which uses COM-basedstandards for communication and application 530 on web server 500 thatuses web-based protocols). In the embodiment shown, COM adapter 320translates COM-based communication from application 310 to HTTP-basedcommunication, and translates HTTP-based communication to COM-basedcommunication for receipt by application 310. COM adapter 320 may have aseries of programmed routines designed to perform this translation.However, the COM adapter is not limited in this regard, as it may beimplemented in software, hardware, firmware or combinations thereof. Inaddition, it should be appreciated that the present invention is notlimited to use on a system employing a COM adaptor that performs anyparticular type of translation between communication formats, as thepresent invention can be used upon a system that enables communicationbetween applications employing different communication protocols in anysuitable manner.

For example, although the implementation depicted provides forinter-process communication using HTTP, other implementations mayprovide for communication using various other protocols. As such, othertranslation facilities can be employed rather than COM adapter 320. Insome implementations, no translation facility at all is employed (e.g.,if no COM-based applications are employed or if the applications arecapable of communicating using a common protocol).

In the embodiment shown, COM adapter 320 accepts outgoing communicationfrom application 310 at a CM interface 315. The COM adapter 320translates those COM-based communications to HTTP-based communications,and transmits them to the CM interface 420 of a context manager session410A executing on a context management server (referred to as a contextserver) 400. Similarly, COM adapter 320 receives at CP interface 375incoming messages, in HTTP format, that are transmitted from the contextserver 400 to application 310, translates those communications to theCOM-based protocol and forwards them to the CP interface 325 for theapplication 310.

As mentioned above, the desktop 300 also executes a browser 330. Brower330 communicates with a web server 500 via a network 700. As definedherein, the term “browser” refers not only to web-based applicationsconventionally referred to as browsers, but also any other application(e.g., implemented using Java applets) that sends or receives data usingHTTP (or other web-based protocol), and that, like a web-based browser,separates the user interface from the corresponding application programin a manner such that updates of the application program are notautomatically sent to the user interface. Similarly, web server 500 maycomprise any suitable hardware, software or combination thereofconfigured to send and receive web-based communication. Network 700 maycomprise the Internet, a local area network (LAN), other communicationsinfrastructure, or combinations thereof, and may use any suitablecommunications protocol.

Web server 500 executes a web-based context participant application 530.In a conventional manner, browser 330 may display information (e.g., webpages) transmitted by application 530, and accept input from a user(e.g., in the form of keystrokes, mouse movements and the like), andtransmit those inputs to application 530 for processing. However, thepresent invention is not limited to use with web-based applications thatare implemented in any particular manner, as browser 330 and web server500 may distribute processing associated with application 530 in anysuitable manner.

The illustrated desktop 300 also executes a emulation client 340, whichis in communication with a remote application server 600 to initiate asession 610 within which one or more context participant applicationsmay execute. The emulation client 340 may establish session 610 andcontact the remote application server 600 to obtain a set of availableapplications. In response, the server 600 may transmit a list ofapplications available for use, using any of numerous techniques. Forexample, when using the Citrix MetaFrame and ICA client architecture, aset of available applications may be transmitted over the Citrix ICAprotocol. In the illustrative implementation depicted, remoteapplication 615 has been selected by the user as a context participantand is a COM-based application. In the embodiment shown, the remoteapplication server 600 includes a COM adapter (CA) 617 that translatesCOM-based communications from the application 615 to HTTP-basedcommunication (and vice versa) for communication with the CM interface420 of the context manager session 410A, in much the same manner as theCOM adapter 320 discussed above.

Input to the remote application 615 (e.g., in the form of keystrokes andmouse movements), is sent from emulation client 340 to server 600 viaconnection 631 (e.g., a virtual channel created using the Citrix ICAprotocol), and commands embodying resulting screen changes in the userinterface on client 340 are returned from the server 600 to theemulation client 340 via connection 631. The connection 631 can beimplemented over any physical communication medium, including the samenetwork 700 that connects the desktop 300 to the web server 500. Inaddition, the same network 700 may also be used for communicationbetween the desktop 300 and the context vault 400, as well as betweenthe context server 400 and each of the remote application server 600 andweb server 500. However, the present invention is not limited in thisrespect, as the embodiments of the present invention can be implementedon any type of computer system configuration, including systems usingany type of interconnections between the various system components.

Desktop 300 may comprise any of numerous computing facilities capable ofexecuting the applications discussed above, as the embodiments of thepresent invention are not limited to use with any desktop computingplatform. For example, desktop 300 may comprise a personal computer,server, handheld computing device, or other type of computing facility.Additionally, although COM-based applications typically execute in aWindows environment, desktop 300 is not limited to the execution of anyparticular operating system.

In the embodiment shown, context server 400 executes multiple contextmanager sessions 410A-C. However, the embodiments of the presentinvention are not limited to use with a context management servercapable of executing multiple context manager sessions. Furthermore, theembodiments of the present invention described herein can alternativelybe employed in a system that includes multiple context servers, eachcapable of executing one or more context manager sessions. In oneembodiment, context server 400 is implemented as a server appliance, asdescribed in commonly assigned U.S. patent application Ser. No.09/583,301, which is incorporated herein by reference. However, theembodiments of the invention are not limited to use with a contextmanagement server implemented in this manner, as the context server 400may comprise any suitable computing platform, such as a general-purposeserver or other computing device. Indeed, although context server 400 isdepicted in FIG. 2 as a device which is separate from desktop 300, thesystem is not limited in this regard, as the context manager session canbe executed on the desktop 300.

In the system depicted in FIG. 2, context manager session 410A managescontext for all the applications represented, including COM-basedapplication 310, web-based application 530, and the remote application615. To communicate with COM-based application 310, context managersession 410A transmits messages to COM adapter 320 via CP interface 375,and receives messages from COM adapter 320 via CM interface 420. Tocommunicate with web application 530, context manager session 410Atransmits messages to web server 500 via CP interface 510 and receivesmessages from web server 500 via CM interface 420. Finally, tocommunicate with the remote application 615, context manager session410A transmits messages to COM adapter 617 executing on remoteapplication server 600 via CP interface 640, and receives messages fromCOM adapter 617 via CM interface 420.

Conventionally, TCP/IP communication between a browser and web server isonly initiated by the browser for security reasons. Specifically, if aweb server knew the identities of the browsers with which itcommunicates, a security breach at the server could give an intruder theidentity of a number of vulnerable targets. For this reason networkrestrictions are typically employed so that the server responds tocommunications from the browser, but does not initiate suchcommunications.

When a web application participates in a context, it may be theapplication (e.g., application 530 in FIG. 2) executing on the webserver that is the context participant, rather than the browser. Asdiscussed above, in accordance with the CCOW standard, when a change tothe context is executed, the context manager publishes the changedecision to the applications in the context. In the case of a webapplication, when the change in context occurs, the change takes placein the application 530 on the web server 500. However, because the webserver does not initiate communication with the browser, the browser 330may not be automatically made aware of the change, such that therepresentation of the state of the application 530 on the desktop 300may be inaccurate. Thus, in accordance with one embodiment of thepresent invention, a technique is employed to enable a browser to bemade aware that a change has taken place in a corresponding webapplication, so that the browser can request the web server to provideit with updated information.

In accordance with the CCOW standard, a listener 335 is employed toassist in instructing the browser 330 to request updated informationfrom its corresponding web server 500 when a change has been made to theweb application 530 executing thereon. In the CCOW standard, thelistener 335 provides an interface that the instigator application cancontact to inform it that a change in the context has been made, so thatthe listener 335 can instruct the browser 330 to go back to the webserver 500 for an update. The listener 335 can be implemented as astand-alone module, as part of the browser 330, or as part of any othercomponent of the desktop 300, as the present invention is not limited toany particular implementation.

The updating of the listener 335 can, similarly, be implemented in anyof numerous ways. In accordance with one embodiment of the presentinvention, when the context manager (e.g., session 410A) returns thesurvey information to the instigator application relating to a requestedchange, the context manager also provides a list of URLs (correspondingto the listeners for any web-based applications in the context) to theinstigator application, instructing the instigator application tocontact (or “touch”) those URLs to inform them that the context has beenupdated.

As shown in FIG. 2, when the instigator application is anotherapplication executing on the same desktop 300 as the browser 330 (e.g.,the COM-based application 310), the instigator application can directly(e.g., through the COM adapter 320) contact the listener 335, as the URLfor the listener 335 will be accessible from within the desktop.

Communication between the instigator application and the listener 335,like other communication between different computers in the contextmanagement architecture discussed above, is complicated when two or moreof the computers are on opposite sides of a firewall, VPN or othersecurity facility that employs NAT. In the illustrative implementationshown in FIG. 2, such a VPN 800 is shown around the desktop 300. Becauseof the VPN 800, components of the computer system that are not on thedesktop 300 may have difficulty in initiating communication with any ofthe components on the desktop, such as the listener 335 or the COM-basedapplication 310.

For example, if COM-based application 310 initiates a context change, itmay send a communication to context manager session 410A. Thecommunication will be altered by VPN 800 to obfuscate the true identity(typically expressed as the IP address) of the originating applicationwithin the VPN 800. As a result, an originating IP address of, forexample, “172.20.10.5” may be changed to another address such as“10.10.10.5”. With a masking utility such as NAT, once a connection hasbeen established (e.g., between the COM adapter 320 and the contextserver 400), bidirectional communication through that connection (oropen channel) is supported. For example, a masking utility such as NATmay keep track of the outgoing communication so that it can route aresponse back to the sender of an originating message (e.g., if contextmanager session 410A responds to application 310 at IP address“10.10.10.5”, the masking feature may perform a reverse conversion,thereby directing the message back to IP address “172.20.10.5”).

While components within the VPN 800 can initiate communication withcomponents outside the VPN, the reverse is not true. For example, ifcontext manager session 410A sends an unsolicited message (for example,a survey issued as a result of another application seeking to instigatea context change) intended for application 310 at either of IP addresses“10.10.10.5” or “172.20.10.5”, the VPN 800 may refuse to let the messagepass. A similar problem is encountered when an application outside ofthe VPN 800 is an instigator application that seeks to contact thelistener 335 to instruct it to touch its browser to seek an updated pagefrom its corresponding web server in response to a context change. Inthis respect, the URL that the context manager will provide to theinstigator application along with the survey results is the URL that thelistener 335 passes along to the context manager as its contact address.However, the URL will be an address accessible only within the VPN 800,such that any attempt to access the listener 335 from an instigatorapplication outside of the VPN 800 will be unsuccessful.

In accordance with the CCOW standard, a desktop executing a COM-based orweb-based application also includes a Context Management Registry (CMR)interface that the desktop can query to determine the identity (e.g.,find the URL for) a context manager to manage a context. In theembodiment of the invention illustrated in FIG. 2, the CMR interface 352is implemented by a vergence locator 350 provided on the desktop 300,with the CMR interface 352 being a plug into the vergence locator 350.The CMR interface 352 can be queried by the COM-based application 310(via the COM adapter 320) or the browser 330 to request the identity ofthe appropriate context manager (e.g., one of the context managersessions 410A-C). When a context is initially being established (suchthat no context manager has been assigned to it), the vergence locator350 uses a URL provided in the CMR interface 352 to contact the contextmanagement server (e.g., context server 400) to initiate a contextsession. The communication from the vergence locator 350 to the contextserver is directed to a location service (LS) (having a plug 421) thatforms part of a context system 423 that manages the multiple contextmanager sessions 410A-C. Thus, this communication goes through a privateinterface, rather than through the CM interface 420 for any contextmanager session. However, it should be appreciated that the presentinvention is not limited in this respect, and that communication betweenthe vergence locator and the location service in the context system 423can be accomplished in any suitable manner.

When the vergence locator 350 contacts the location service of thecontext system 423 to request a new context manager session, the contextsystem 423 initiates a new context manager session 410A-C and returns tothe vergence locator 350 a URL that uniquely identifies the CM interface420 for the new context manager session.

In the embodiment shown, the browser 330 can obtain the URL, via thevergence locator, from the context manager and provide it to itscorresponding web application 530, which may then access the contextmanager directly in the manner described below.

In the illustrative embodiment shown, each remote application serverexecuting an application that may share a context (e.g., server 600)also includes a vergence locator 620 that performs functions similar tothe vergence locator 350, including the implementation of a ContextManagement Registry interface (not shown) that enables the remoteapplication server to locate the URL for the context manager andinitiate a context management session in the manner discussed above.

One aspect of the invention provides a technique for facilitatingcommunication between two components on opposite sides of a securityfacility in a system that implements context management. In oneembodiment, the technique involves establishing a network connectionbetween the desktop (or remote application server) and the contextmanager, and maintaining the connection for the period of time duringwhich any of the applications on the desktop (or the remote applicationserver) share a context that either (1) includes one or more participantapplications executing on a computer on the opposite side of a securityfacility or (2) is managed by a context manager executing on a computeron the opposite side of a security facility. According to oneembodiment, the connection is a TCP/IP back-channel connection betweenthe context management server (e.g., context server 400) and the client(e.g., desktop 300 or remote application server (e.g., server 600),which may be initiated by a client or remote server communication to thecontext management server, as described below. However, this aspect ofthe present invention is not limited in this regard, as any connectionwhich is maintained over the relevant period of time may be employed.

In one embodiment, when a context environment is initially set up, aTCP/IP back-channel is established between the context management server(e.g.) vault 400A and the vergence locator 350 on the client desktop300. The TCP/IP back-channel is a durable connection that lasts beyondthe specific communication session necessary to establish the contextenvironment, but rather, is maintained during the entire time periodduring which an application on the desktop 300 shares a context eitherwith another application on the opposite side of a security facility(e.g., VPN 800), or participates in a context managed by a contextmanager on the opposite side of a security facility. The back-channelprovides an open communication path from the context server 400 to thedesktop 300, so that a context manager session (e.g., 410A) can initiatecommunication with the desktop 300, or pass along communications to thedesktop 300 from one of the other applications (e.g., the web-basedapplication 530 or the remotely executing emulated application 615) inthe context.

One exemplary implementation of the embodiment of the present inventionthat employs a backchannel between the vergence locator and the contextmanager is shown in FIG. 2. Each context manager session 410A-C caninclude a backchannel (BC) plug 425 that can be used for communicationwith the vergence locator to establish the backchannel. In FIG. 2, onlyone backchannel plug 425 and one CM interface 420 is shown, but itshould be appreciated that one of each may be provided for each contextsession. Thus, in the embodiment shown, the backchannel communicationdoes not pass through the context manager interface 420 for the contextmanager session. However, it should be appreciated that the embodimentof the present invention that employs a backchannel is not limited toany particular implementation, as numerous alternative implementationsare possible.

According to one embodiment, the vergence locator 350 receivescommunication via the back-channel from context manager 410A and relaysit to the appropriate entity on the desktop 300. For example, if contextmanager 410A issues a survey communication intended for COM-basedapplication 310 to determine whether a context change instigated by webapplication 530 is acceptable, context manager 410A can transmit thecommunication via the back-channel to vergence locator 350. The ultimatedestination for the communication can be identified in any of numerousways, such as by a URL previously provided by the desktop 300 to thecontext server 400 for such communications (e.g., a URL for the CPinterface 375). Because the CP interface 375 and the vergence locator350 are both behind the VPN 800, the vergence locator 350 can forwardthe communication directly to the specified URL for the CP interface 375using any suitable technique. The CP interface 375 will then forward thecommunication to the COM-based application 310 in the manner discussedabove. It should be appreciated that the manner in which the vergencelocator 350 identifies the appropriate entity in the desktop 300 towhich communications received over the back-channel are relaying is notlimited to any particular implementation, as numerous techniques arepossible.

In the manner described above, a context manager executing on a serveroutside a firewall or other security facility may initiate communicationwith applications executing behind a firewall, using a technique whichdoes not require knowledge of the IP address for any entity on thedesktop.

In one embodiment of the present invention, techniques are employed toensure that when a connection (e.g., the backchannel connectiondiscussed above) is established between a desktop or remote applicationserver and the context management server, the connection is secure, suchas by verifying that the desktop or remote application server isauthorized to establish the connection. In one embodiment, theverification is performed using digital signatures, although the presentinvention is not limited in this respect, as any suitable technique maybe employed.

In one embodiment of the present invention, heartbeat or pingingtechniques can be employed between the desktop 300 and the contextserver 400 to ensure that the back-channel path remains open, so that inthe event that the back-channel is lost for any reason, it can bere-established by the desktop 300.

It should be appreciated that a remote application server (e.g., theserver 600) may also be configured in computer systems wherein they areprotected by a security facility, such as a firewall or VPN. Thus, inaccordance with one embodiment of the present invention (not shown), aback channel can similarly be established between the vergence locator620 of the remote application server 600 and the context server 400 in amanner similar to that discussed above. It should be appreciated that aback-channel can similarly be formed between the context server 400 anda web server executing an application in a shared context, but that sucha back-channel will normally be unnecessary in view of the fact that webservers are typically exposed, rather than being protected behind asecurity facility, such that the context server 400 can typicallyinitiate communications directly with a web server.

In another embodiment of the present invention, communication betweenthe context manager and a context participant application is facilitatedacross a firewall without requiring a durable network connection to bemaintained throughout the life of the context. It should be appreciatedthat there are at least two alternate configurations in which thecontext manager can be on the other side of a firewall from a contextparticipant. An illustrative example of a first is depicted in FIG. 4,in which context participant application 715 executes on desktop 710behind firewall 740, while context management server 720 is disposedoutside the firewall 740. An illustrative example of a secondconfiguration is depicted in FIG. 5, in which the context manager 815executes on desktop 810 behind firewall 850, while separate contextparticipant applications execute on web server 820 and remoteapplication server 830, which are each disposed outside the firewall850.

According to one embodiment, described with reference to theconfiguration depicted in FIG. 4, communication from a contextmanagement server 720 to a context participant application 715, disposedbehind a firewall 740, is enabled with a context participant gateway730. In the embodiment shown, context participant gateway 730 isimplemented on a separate server, and a “small” hole in the firewall 740is provided to enable limited communication thereto. That is, thecommunication that passes through the firewall 740 can be limited tocommunications that originate from the context management server 720,and/or are of the specific types employed in the context managementprotocol for communication from a context manager to a contextparticipant. Communication from the context manager 720 to contextparticipant application 715 is routed through the context participantgateway 730 to the participant application 715 in any suitable manner.For example, techniques can be employed that are similar to thosediscussed above wherein communication from the context manager is sentto the vergence locator 350 (FIG. 2) and forwarded to the contextparticipant application, with the exception that the context participantgateway 730 may be disposed on a different computer from the contextparticipant application, whereas the vergence locator is provided on thesame desktop. In this manner, the context participant gateway 730 canallow only communications directed to a context participant application(or associated listener) to pass through the firewall.

In an alternate embodiment, described with reference to theconfiguration depicted in FIG. 5, communications from contextparticipant applications running on servers 820, 830 to a contextmanager 815, which is disposed behind firewall 850, are enabled in ananalogous manner with context manager gateway 840. As with theconfiguration depicted in FIG. 4, the context manager gateway 840 may beprovided on a separate server, and a “small” hole in the firewall can beemployed to allow communication to the context manager gateway 840, butonly from computers 820, 830 which are recognized to be executingcontext participant applications, and only communications directed tothe context manager 815. The context manager gateway 840 can forwardsuch communications to the context manager 815 in a manner similar tothat described above. As described above, one configuration wherein acontext manager gateway may be useful is when the context manager isprovided on a desktop with one or more context participant applications.

Referring again to FIG. 2, remote application 615 executes within asession 610 on server 600. In the implementation depicted, server 600 isa separate computer from desktop 300, and is disposed on the oppositeside of VPN 800, so that the remote application server 600 cannot sendunsolicited communication to applications executing on desktop 300. Asdiscussed above, the CCOW standard specifies that when an applicationinstigates a context change, the context manager supplies a list oflisteners for web-based applications in the context, and the instigatorapplication touches those listeners when the change decision ispublished. Thus, when the remote application 615 is the instigator of achange request, the VPN 800 prevents it from touching the listener 335executing on the desktop 300 when a change decision is published.

In accordance with one embodiment of the present invention, amodification to the CCOW standard is implemented, wherein rather thanhaving the instigator application touch the listeners for any web-basedcontext participants when a change decision is published, the contextmanager touches the listeners. This aspect of the present invention canbe used in conjunction with the embodiment of the present inventiondiscussed above wherein an open communication channel is maintainedbetween the context server 400 and any of the computers that have anapplication executing in the context and are behind a security facility,so that the context manager has the ability to touch the listener foreach of the web-based applications in the context.

As discussed above, in the CCOW standard, when an instigator applicationrequests a context change, the context manager conducts a survey of theother applications in the context, and returns the results to theinstigator application, along with a list for the instigator applicationto use to touch the listeners for any web-based participants. Inaccordance with one embodiment of the present invention, a list oflisteners to be notified need not be returned to the instigatorapplication, as the instigator application need only inform the contextmanager of the decision, and the context manager publishes the decisionand contacts the listeners directly.

The inclusion of remote application servers (such as server 600) withina context management system raises additional concerns regarding theintegrity of a context. For example, when a plurality of contextparticipants includes a remote application (e.g., application 615) andone or more desktop applications, it may be desirable to verify that theremote application and the desktop application(s) are associated withthe same client (e.g., that the emulation client 340 and COM-basedapplication 310 execute on the same desktop 300), to guard against arogue application intruding in a context. Accordingly, one embodiment ofthe invention provides a technique to match a remote application to theclient device on which it is emulated. In one embodiment, a uniqueclient identifier is received from the client and from the remoteserver, and the identifiers are compared to determine whether the remoteapplication is emulated on a “trusted” client, e.g., one that includesanother application in the context.

In one embodiment, the vergence locator 620 issues a command to theemulation client 340 requesting a unique identifier for the client. Theclient 340 queries desktop 300 for an identifier which uniquelyidentifies the desktop, and transmits a response back to the remoteapplication server 600. This may be accomplished using any of numeroussuitable techniques. In one embodiment, the emulation client 340 calls adynamic link library (DLL) to query desktop 300 for at least one MediaAccess Control (MAC) address, which is a unique hardware identifierassigned to each of the desktop's network adapters. The MAC address isthen returned to the remote application server 600. The context server400 similarly queries desktop 300 (e.g., over the back-channel) for theMAC address. Thus, when an application executing on the remoteapplication server 600 seeks to be added to a context, it provides theMAC address it receives for the client to the context server 400, whichcompares that MAC address with one received directly from the client. Amatching set of MAC addresses confirms that remote application 615 isemulated on an emulation client 340 on the same desktop on which othercontext participant applications execute, so the remote application isadded to the context. Alternatively, if the MAC addresses do not match,the remote application is not added to the context, because it is notemulated on the same desktop as the other applications in the context.

The desktop may comprise multiple network adapters. In one embodiment,the DLL is configurable to concatenate, or otherwise combine or modify,multiple MAC addresses to form a single unique identifier that can beused in the above-described matching process. It will be appreciatedthat the embodiment of the present invention that employs a MAC address(or some unique identifier derived therefrom) is not limited toconcatenating or combining multiple MAC addresses in any particular way,as any suitable technique can be employed, including the selection of aparticular one of the MAC addresses for use as the unique identifier.

Communication between the remote application server 600 and theemulation client 340 to receive a unique identifier can be accomplishedusing any suitable technique. In one embodiment for use with the CitrixMetaFrame and ICA client architecture, the Citrix-provided capability toimplement a virtual channel on top of connection 631 between the clientand server is used to transmit information between the Citrix MetaFrameserver 600 and the Citrix ICA client 340.

Verifying that a remote application and other context participantsoriginate from the same client may be performed in any of numerous ways,as the invention is not limited to the above-described techniques. Forexample, the unique client identifier need not be a MAC address, and canbe any information that can be used to identify the client.

In some computer system configurations, an emulation client 340 mayemulate multiple remote applications which each execute on differentremote application servers. In accordance with one embodiment of thepresent invention, a technique is employed to ensure that the multipleapplications executing on different remote application servers belong tothe same emulation client, and therefore are on the same desktop and canshare a context. In a manner similar to that described above, thisprevents a rogue application from improperly intruding into a context.

In accordance with one embodiment of the present invention, anidentifier that uniquely identifies the emulation client 340 isrequested by each remote application server, and is provided from theremote application server to the context manager. The context managerfurther requests the unique identifier(s) directly from the emulationclient, and then compares the identifiers to ensure a match in much thesame manner as discussed above. In accordance with one embodiment of thepresent invention, the unique identifier may be a hardware MAC address(or any other suitable identifier) as discussed above.

It should be appreciated that a desktop machine on which a clientemulation program executes may be incapable of providing its MACaddress. For example, in some system configurations, a facility such asthe DLL described above may not be present, such as a configuration inwhich a user employs an unmodified laptop computer to dial into a remoteapplication server. Thus, one embodiment of the present inventionprovides for an alternative identifier to be employed to uniquelyidentify the emulation client.

In accordance with one embodiment of the present invention for use withthe Citrix MetaFrame and ICA client architecture, an embodiment of thepresent invention makes use of a Citrix application programminginterface (API) that provides information relating the client. Inaccordance with the Citrix-provided API, the login of the user on theclient, and the IP address and a client host name (that typicallydefaults to the name of the computer on which the client is executing)for the client machine can be provided. In accordance with oneembodiment of the present invention, these three pieces of informationare employed to verify a match of the client, such that each of thethree pieces of information must be identical for a match to berecognized. Thus, when a user at a single emulation client logs into tworemote application servers, in accordance with one embodiment of thepresent invention, the user employs the same login identifier on both.The two remote application servers use the Citrix-provided API toretrieve the above-described identifier information from the client andprovide the identifier information to the context manager. The contextmanager verifies that the identifier information matches to determinethat the two remote applications are emulated on the same emulationclient, and can therefore belong to the same context.

It should be appreciated that the embodiment of the present inventionthat collects unique identifier information from the client machine isnot limited to employing the Citrix-provided API to collect information,as other implementations are possible. In addition, it should beappreciated that the aspects of the present invention that facilitatecontext management with remotely emulated applications are not limitedto use with the Citrix MetaFrame and ICA client architecture, as otheremulation architectures can be employed. When a different emulationarchitecture is employed, the clients may be provided with alternateapplication programming interfaces that allow for the collection ofdifferent types of information. Thus, the above-described implementationis merely illustrative, and simply makes use of the Citrix-provided APIto collect information from which a client can be uniquely identified.The present invention is not limited to using the types of informationdescribed above, as any suitable information that uniquely identifiesthe client can be employed.

In an alternate embodiment of the present invention, the identifiersprovided by the remote application servers to identify their associatedclients need not be identical, as the client can provide information tothe context manager to enable the context manager to determine that tworemote applications may in fact be emulated on the same emulationclient, even if they provide different identifiers. For example, if anemulation client were to use a different user ID and/or password to loginto two different remote application servers, the emulation client canprovide both sets of identifiers to the context manager in a manner thatmakes clear to the context manager that both sets of identifiersidentify the same emulation client. The context manager can then usethis information to determine that two remote application servers thatprovide different types of identifiers for an emulation clientnevertheless are emulated on the same emulation client.

As should be appreciated from the foregoing, the present invention isnot limited in any manner to the nature of the identifiers provided fromone or more remote server applications and emulation clients to thecontext manager to enable the context manager to determine that theremote server applications are emulated on the same client, as numerousimplementations are possible.

Some remote application and emulation client configurations (e.g., theCitrix MetaFrame and ICA client architecture) enable an emulation clientto not only emulate specific applications, but also allow a client toemulate (or “publish”) entire processing environments (“desktops”),which may include icons allowing the client to execute otherapplications remotely. There are numerous possibilities for the mannerin which this can be configured. For example, a Citrix ICA client mayemulate a desktop environment executing on a first Citrix MetaFrameserver, and the desktop may provide access to one or more applicationswhich execute on a different (or “downstream”) Citrix MetaFrame server.Such a configuration is illustrated in FIG. 3. In accordance with oneembodiment of the present invention, a technique is provided to verifythat a remote application executing on a downstream remote applicationserver is emulated on the same client as other context participants, andcan thus participate in a context with them.

In one embodiment, an identifier that uniquely identifies the emulationclient is provided to the downstream remote application server, whichthen provides the unique identifier to the context manager for matchingwith an identifier that the context manager retrieves directly from theclient machine, in much the same manner as described above.

In the configuration depicted in FIG. 3, emulation client 340 emulates aremote desktop session 610 executing on remote application server 600.Session 610 is provided in the form of a desktop, from which emulationclient 340 may launch one or more applications (e.g., applications 612and 615). In the configuration shown, when application 615 is launched,it is executed on the remote application server 600, within session 610.However, application 612 is a client application for a remotelyexecuting application 665, so that when application 612 is launched, itinitiates the application 655 in a session 660 on downstream remoteapplication server 650. This may occur in a manner which is transparentto emulation client 340. During the execution of application 665, clientapplication 612 persists within session 610 as an emulation ofapplication 665, which facilitates communication between emulationclient 340 and application 665.

In one embodiment, remote application server 600 and downstream remoteapplication server 650 include vergence locators 620 and 670,respectively. During the process of determining whether remotelyexecuting applications can participate in a context, the vergencelocators 620 and 670 each contact their corresponding client (e.g. usingthe Citrix-enabled virtual channel—see 631 in FIG. 2—when in a systemthat employs the Citrix MetaFrame and ICA client architecture), torequest that their corresponding client return a unique identifier inthe manner described above. In the configuration shown in FIG. 3, thedesktop is provided with a DLL 341 that provides the ability for theemulation client 340 to obtain a MAC address for a network adaptor onthe desktop 300. Thus, in one embodiment, the vergence locator 620contacts the emulation client 240 and request the MAC address.Similarly, the vergence locator 670 contacts the client on which theapplication 665 is emulated, which client is the application 612executing on the remote application server 600. In accordance with oneembodiment of the present invention, when the DLL 613 associated withthe client application 612 receives this request, the DLL will query theserver on which it is executing (i.e., server 600) to determine whetherthe server is a remote application server. If so, the DLL 613 will notreturn a MAC address for the remote application server 600, but rather,will contact the vergence locator 620 to obtain the MAC address for theclient (i.e., emulation client 340) on which the remote application 612is emulated. In this manner, both the application 615 executing on theremote application server 600 and the application 665 executing on thedownstream remote application server 650 will return to the contextmanager the same MAC address for the desktop 300, enabling the contextmanager to verify that these applications are emulated on the sameclient and can participate together in a context.

It should be appreciated that the aspect of the present invention thatrelates to determining an identifier for an end of the line client onwhich a published application is ultimately emulated is not limited to a2-level emulation environment as shown in FIG. 3, as the above-describedtechniques can be employed on deeper hierarchical configurations havingany number of levels.

In the embodiment described above in connection with FIG. 3, the end ofthe line client machine (i.e., desktop 300) on which the remoteapplications are emulated has an associated DLL 341 that provides thecapability to retrieve the MAC address for the client machine. As theMAC address provides a verifiable unique identifier for the client,embodiments of the present invention that are used in connection withsuch configurations can support context sharing amongst remoteapplications across numerous configurations, including differentpublished desktops.

It should be appreciated that the aspects of the present inventiondescribed herein are not limited to use with an emulation client thathas a DLL or other facility to allow for the retrieval of a uniquehardware identifier. In accordance with one embodiment of the presentinvention for use in connection with a client that has no such ability,a restriction is placed on context sharing between remote applications,such that remote applications can only share a context if they areexecuting on, or remotely emulated on, the same desktop, such as thepublished desktop session 610 in FIG. 3. In accordance with thisembodiment of the present invention, when the vergence locator 670 onthe downstream remote application server 650 seeks a unique identifierfor its corresponding client, the DLL 613 returns a MAC address for theremote application server 600, and also a unique identifier for thepublished desktop session 610. Thus, when the context manager reviewsthe returned identifiers to determine whether the applications 665 and615 can share a context, it verifies that these applications are notonly executing and/or emulated on the same machine (i.e., remoteapplication server 600), but that they are in the same published desktopsession 610.

As mentioned above, the computer system configuration shown in FIG. 2 ismerely illustrative, as numerous other configurations are possible. Forexample, in the illustrative configuration of FIG. 2, the applicationsexecuting on the remote application server 600 are COM-basedapplications. However, it should be appreciated that web-basedapplications can also be implemented on a remote application server. Forexample, a browser can be executed on the remote application server andemulated on an emulation client such as client 340 in FIG. 2. In such aconfiguration, the listener 335 illustrated in FIG. 2 can be implementedon the remote application server along with the browser, and can beaccessed in substantially the same manner as discussed above (e.g.,through a back-channel established between the context server 400 andthe vergence locator 620 on the remote application server 600).

Referring to the exemplary configuration of FIG. 2, components thereofthat support context management include the context server 400, thevergence locator 350, listener 335, COM adapter 320, CM registry 352,and the CM and CP interfaces 315, 325 and 375 on the desktop, as well asthe CP interface 510 for the web server, and the vergence locator 620,COM adapter 617 and CP interface 640 on the remote application server600.

It should be appreciated from some configurations are possible whereinthe desktop 300 consists solely of an emulation client for one or moreremote server applications. As should be appreciated from thedescription above, the desktop itself need not include any components tosupport context management, as all of that support can be provided onthe context manager 400 and one or more remote application servers 600.

It should be appreciated that although the foregoing discussionspecifically describes implementing context management in a networkedenvironment using the CCOW standard, aspects of the present inventiondescribed herein are not limited in this respect, and can be employed toimplement context management in other ways that are not limited to theCCOW standard.

The above-described embodiments of the present invention can beimplemented in any of numerous ways. For example, the embodiments may beimplemented using hardware, software or a combination thereof. Whenimplemented in software, the software code can be executed on anysuitable processor or collection of processors, whether provided in asingle computer or distributed among multiple computers. It should beappreciated that any component or collection of components that performthe functions described above can be generically considered as one ormore controllers that control the above-discussed functions. The one ormore controllers can be implemented in numerous ways, such as withdedicated hardware, or with general purpose hardware (e.g., one or moreprocessors) that is programmed using microcode or software to performthe functions recited above.

In this respect, it should be appreciated that one implementation of theembodiments of the present invention comprises at least onecomputer-readable medium (e.g., a computer memory, a floppy disk, acompact disk, a tape, etc.) encoded with a computer program (i.e., aplurality of instructions), which, when executed on a processor,performs the above-discussed functions of the embodiments of the presentinvention. The computer-readable medium can be transportable such thatthe program stored thereon can be loaded onto any computer systemresource to implement the aspects of the present invention discussedherein. In addition, it should be appreciated that the reference to acomputer program which, when executed, performs the above-discussedfunctions, is not limited to an application program running on a hostcomputer. Rather, the term computer program is used herein in a genericsense to reference any type of computer code (e.g., software ormicrocode) that can be employed to program a processor to implement theabove-discussed aspects of the present invention.

It should be appreciated that in accordance with several embodiments ofthe present invention wherein processes are implemented in a computerreadable medium, the computer implemented processes may, during thecourse of their execution, receive input manually (e.g., from a user),in the manners described above.

Having described several embodiments of the invention in detail, variousmodifications and improvements will readily occur to those skilled inthe art. Such modifications and improvements are intended to be withinthe spirit and scope of the invention. Accordingly, the foregoingdescription is by way of example only, and is not intended as limiting.The invention is limited only as defined by the following claims and theequivalents thereto.

1. In a system comprising a first client, a context management (CM)server, a remote application server and at least one network thatcouples together the first client, the CM server and the remoteapplication server, the remote application server executing at least oneremote application, the first client executing at least one clientapplication that may share a context with the at least one remoteapplication, the first client further executing an emulation applicationthat emulates that at least one remote application on the first client,the CM server executing a context management service to manage thecontext, a method of verifying that the at least one remote applicationis emulated on the first client and may belong to the same context, themethod comprising acts of: (a) receiving from the first client firstinformation that uniquely identifies an aspect of the first client; (b)receiving from the remote application server second information thatuniquely identifies the aspect of a remote client on which the remoteapplication is emulated; and (c) determining that the at least oneremote application is emulated on the first client and may belong to thesame context when the first information matches the second information.